home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 5675 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB

  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Speed:  68040 vs. 68060
  5. Date: Fri, 23 Feb 96 19:03:04
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960223.425E10.10CBD@an100.du.pipex.com>
  9. References: <4foi00$60t@gondor.sdsu.edu> <3125E74D.3390@gih.no>
  10. NNTP-Posting-Host: an100.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Lee Huggett (Lee@burst.demon.co.uk) wrote:
  14. : > Full bullshit. I complied a simple real-world test,
  15. : > and it was about 2x fast as on my 040/40 Warp Engine,
  16. : > and about a same on P90.
  17. : Hey Hey Hey don't start getting fucking nasty...
  18. : What simple real world test??
  19. : Mail it to me and I'll give it a try...
  20.  
  21. Try the BYTEMark tests on Aminet, which contain compiled algorithms designed
  22. to simulate real world applications. They are scaled to performance - faster
  23. CPUs are given bigger tasks. The results are benchmarked relative to a Dell
  24. P90, which was quite humbling for my poor Amiga and its aging 40MHz '030 :(
  25. (approx. 10% of a P90 for integer routines, BTW. Even slower for FP)
  26.  
  27. : > SysInfo is crap, that 40MIPS is really wrong. My 040/40
  28. : > does that.
  29. : I was mearly stating a fact Sysinfo does give 40 MIPS for an '060
  30.  
  31. The speed tests used in SysInfo fit completely in a 68040's internal cache,
  32. and therefore also in the larger cache in the 68060. For this reason, and
  33. others, they do not provide a reliable estimate of real world performance.
  34. Cache latency, memory access speeds and other factors must also be taken into
  35. account. On an '040 or '060 MisInfo can't even attempt to do this. You might
  36. as well be testing an endless loop which JMPs directly to itself ;)
  37.  
  38. : and seing as AIBB doesn't recognise the '060 to the point of not working at
  39. : all, we don't really have a lot to work with.
  40. : I know the '060 is faster the 040/40 (I would have bought one of those
  41. : otherwise) but I think it is unlikely that you would get 81 MIPS out of it at
  42. : a sustained rate
  43. :
  44. : > Most of the SAS/C compiled code does not have be specially
  45. : > 68060 optimized, in a real world situation the 060 is
  46. : > usually able to run 2 instructions at the same time.
  47. : If code is optimised for an '060 is has more chance of running 2 or more
  48. : instructions at once then unoptimised code.
  49.  
  50. Only when a compiler appears which produces code optimised for the '060 can
  51. you run such tests. Contriving code in assembly language to take advantage of
  52. new CPU features provides misleading results unless a current compiler (as
  53. used in the REAL WORLD) optimises code in the same way. Since SAS has
  54. apparently abandoned support for SAS C/C++ I don't see this happening anytime
  55. soon. So, your only real world estimates at the moment should be based on
  56. code compiled for the 68040.
  57.  
  58. BTW, as far as I know the current AmigaOS itself doesn't recognise an '060.
  59. The CPU flags in execbase.h only extend up to the 68040. They also show a
  60. possible lack of forethought -
  61.  
  62. /*  Processors and Co-processors: */
  63. #define AFB_68010   0    /* also set for 68020 */
  64. #define AFB_68020   1    /* also set for 68030 */
  65. #define AFB_68030   2    /* also set for 68040 */
  66. #define AFB_68040   3
  67. #define AFB_68881   4    /* also set for 68882 */
  68. #define AFB_68882   5
  69. #define AFB_FPU40   6    /* Set if 68040 FPU */
  70.  
  71. Surely they should have left a gap after AFB_68040 to allow for new additions
  72. to the 680x0 line ;)
  73.  
  74. -- Mat.
  75.